The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
No application can live alone. To run on a computer system, an application requires the presence of other software and hardware components (“external components”) on the computer system and that the external components be installed and configured in a particular way. In addition, the application itself may be comprised of many “internal components” that must also be installed and configured in a particular way. For a particular application, the combination of external and internal components and its configuration is referred to herein as the system configuration.
A system configuration can be very complex. One example of such a system configuration is the configuration of a cluster that hosts a clustered database server. A clustered database server is a database server that runs on a cluster of nodes, referred to herein as a database cluster. Nodes in a cluster may be in the form of computers (e.g. work stations, personal computers) interconnected via a network. Alternatively, the nodes may be the nodes of a grid, where each node is interconnected on a rack. Each node in a database cluster shares direct access to shared-storage resources, such as a set of disks, or a file stored on the disk.
In order to operate correctly and optimally, a clustered database server requires specific storage and network subsystem connectivity, and certain operating system attribute settings. For example, the storage subsystem should be shared between the nodes of a database cluster that host the clustered database server, and there should be at least one private interconnect between the nodes in the cluster.
The task of verifying the configuration and operability of external components and internal components of an application is referred to herein as verification. Verification of external components and internal components of an application occurs throughout the life time of the application.
For example, deployment of an application occurs in stages. Each stage may involve installation and configuration of one or more external and internal components. Deployment of a clustered database server, in particular, entails such stages as a) setup of node interconnect, b) setup of shared-storage system, or c) layout of data files.
The initiation of a stage can depend on the successful completion of one or more other stages. Certain criteria must be satisfied before initiating a stage, i.e. “entry criteria” and after completing the stage, i.e. “exit criteria”. Verification is performed to determine whether the exit or entry criteria are satisfied.
Once initially formed, a clustered database server may continue to evolve, by, for example, adding or replacing nodes in the cluster or upgrading the database server to a new version. Such evolution occurs in stages as well and requires verification to determine whether entry and exit criteria are satisfied.
Finally, bugs and errors may be encountered as an application runs. Resolving such issues often requires verification to determine whether an application and its platform are configured correctly.
Verification is Complicated
Verification of an application, such as a database server, requires a potpourri of tools that are typically provided by vendors of various components. For example, an operating system vendor may provide tools for verifying the operating system, the network vendor may provide tools for verifying the network, and the database vendor may provide tools for verifying individual components. Each tool tests specific components of a system configuration or aspects of those components. To resolve a particular configuration issue, a database administrator (“DBA”) may have to use multiple tools of different vendors. Thus, a DBA responsible for verification of a clustered database server must be familiar with a large number of tools, greatly complicating the task of performing verification.
Not only must the DBA be familiar with multiple tools, the DBA must be knowledgeable about details of the configuration of the database server. Thus, to perform verification, the DBA must be capable of understanding, comprehending, and analyzing many tools and many details of the configuration of a clustered database server.
The verification is further complicated if the DBA is responsible for maintaining multiple clustered database servers for multiple platforms. For example, a DBA may support a database cluster that runs on a first operating system product and another database cluster that runs on a second operating system product. As a result, the DBA may need to be familiar with the operating system tools of two operating system vendors and the configurations of multiple database clusters.
Based on the foregoing, there is a clear need for a way to simplify verification for an application, particularly applications with complex interdependencies between internal and external components.